ACPI is a specification that makes hardware status information available to an operating system in computers, including laptops, desktop, servers, etc. More information about ACPI may be found in the Advanced Configuration and Power Interface Specification, Revision 3.0b, Oct. 10, 2006, cooperatively defined by Hewlett-Packard Corporation, Intel Corporation, Microsoft Corporation, Phoenix Technologies Ltd., and Toshiba Corporation. The ACPI specification was developed, in part, to establish industry common interfaces enabling robust operating system (OS)-directed motherboard device configuration and power management of both devices and entire systems. ACPI is the key element in operating system-directed configuration and power management (OSPM).
ACPI is used in personal computers (PCs) running a variety of operating systems, such as Windows® available from Microsoft Corporation, Linux, available as open source form a variety of vendors, and HP-UX, available from Hewlett-Packard Company. ACPI also allows hardware resources to be manipulated. For example, ACPI assists in power management by allowing a computer system's peripherals to be powered on and off for improved power management. ACPI also allows the computer system to be turned on and off by external devices. For example, the touch of a mouse or the press of a key may wake up the computer system using ACPI.
Traditionally ACPI has been difficult to work with for a variety of reasons. First, ACPI is not written in the native assembly language of any computer system platform. Instead, ACPI has its own source and machine languages, i.e., ACPI Source Language (ASL) and ACPI Machine Language (AML), respectively. Because of its highly specialized use, there are relatively few ASL programmers; ASL has relatively few constructs because of its limited use. Furthermore, ACPI code is conventionally monolithic in its design. Consequently, this makes it difficult to port the ACPI code to other platforms or even to different configurations of the same platform. Thus, new ASL code needs to be written to work with newly-engineered platforms. The limited number of ASL programmers makes writing new code all the more problematic and costly.
ACPI comprises both static and interpretable tables. At boot-up time, the system firmware (typically the BIOS, or Basic Input/Output System) constructs the static tables, which are consumed by the operating system. The interpretable tables are composed of AML, which is compiled and then merged into the system firmware. The operating system reads the AML from the interpretable tables and executes the architected interfaces, using an ACPI interpreter. In this fashion, the operating system manipulates hardware resources. Because the interpretable tables are merged into the system firmware, this conventional method lacks flexibility, and scalability, and requires considerable time to re-program to accommodate divergent system configurations.
Further, native firmware is typically written in a low-level language such as, e.g., assembler language or sometimes in a “C” programming language, while AML runs in a virtual machine referred to as the AML interpreter. Many functional capabilities of native firmware that operate before the AML interpreter is available are also useful during operation of AML control methods. Presently, there is no mechanism to allow an AML control method to access native firmware capabilities. Hence, many functional capabilities are implemented in both native firmware and in AML. This redundancy is expensive and wasteful of resources.